A Comparative Study of RELAX and SysML / KAOS

This report explains two methods used for defining Non Functional Requirements (NFRs). Of the two methods one is RELAX which is a requirements engineering language; used to divide requirements into invariant and RELAX-ed. RELAX-ed requirements can be functional or non functional and is an enhanced form of the original requirement. SysML/KAOS has introduced the concept of goals in SysML; infect the meta model of SysML is extended with the concept of goals. Existing approaches for defining NFRs: In order to define non functional requirements, different questions need to be considered. Following are some of them: • Which process to use for defining NFRs? • Which formalism to use to specify NFRs and the links between them? • How to treat the impact of NFRs on functional requirements? Approach by Chung [1]: It is based on i* approach, used to define NFRs in the form of goal graphs. Put differently a goal should be either satisfied or unsatisfied and nothing else, in every possible imaginable situation. In this context a set of “sub goals” is introduced to satisfy a given goal, where the relationship between sub goals and its parent goal is etiher AND or OR. When the relationship is AND, the goal is satisfied if all of its sub goals are; when the relationship is OR, the goal is satisfied if any of its sub goals is. The i* model is defined by the concept of softgoal which is a NFR that must be satisfied [2]. The authors in [1] are of the view that it is not always possible to satisfy a goal so they have introduced the notion of softgoal for an NFR. A softgoal does not have a clear cut criteria of satisfaction. One softgoal is decomposed into other softgoals and they are linked by the contribution type AND or OR. The decomposition ends when operational softgoals are attained. Approach by Cysneiros [3]: This approach is also based on i* model, it defines how to discover NFRs and study their impact on the conceptual models. It defines a set of rules to realize the traceability between requirement analysis and the UML conceptual models. An NFR graph is created for each NFR, where this NFR is the root of the graph. This graph is further decomposed to express all the operationalizations that are necessary to satisfy the NFR. After having these graphs, one can search for the possible interdependencies among them which can contribute positively or negatively to another NFR. For example an NFR pointing out that the software might need a high level of security may have a negative impact (a negative interdependency) on another NFR like usability.